I would argue against this change because it would require people that already use INA3221 to change the address.

Hey @ngavars, that's understandable but I don't believe anyone will be impacted by this. Unless they do something especially custom, nobody is able to use the INA3211 sensor at all using the current address.

The sensor board only uses two addresses; 0x40 (the default), or 0x41 (set by soldering the Addr jumper on the board). I don't know why someone would be using 0x42 in the first place.

Well, anyone who has repeaters with INA3221 already deployed would be affected by this change, as it would prevent updating firmware without having to take down the node and resoldering the address jumper.
Initially 0x42 was used because it is what MT is using.

It's important to note a few things with this change.

The Adafruit INA3221 uses I2C addresses 0x40 and 0x41 (by soldering the jumper). You can't use an Adafruit INA3221 with Meshcore because the firmware is set to use 0x42 instead.

The current manufacturers of this sensor seem to be limited to 2 producers, Adafruit and generic white labels. There are a few variations of what the white label boards look like, but the functionality is identical.

Adafruit uses the I2C addresses 0x40 (default) and 0x41, while the white label boards use Texas Instruments default of 0x40 (The I2C addresses available is described under section 7.5.1.1 Serial Bus Address). The INA3221 chip supports setting the I2C address as 0x40,0x41,0x42, or 0x43, however the default is 0x40. I have not be able to find a product which uses 0x42 as the default.

This indicates that folks who may be impacted by this change would have to be either:

• Running custom Meshcore firmware with a different I2C address for the sensor.
• Changed the address of the sensor (via hardware or software outside Meshcore)
• Using an INA3221 board which uses 0x42 as the default I2C address.

We don't have any hard data to pull from so I can only speculate on the folks who may be impacted, but it's distinctly niche. The above indicates the potential likelihood of this change impacting someone is significantly small. Anyone who is impacted would have taken that risk when using a configuration outside the standard established by the board manufacturers. Especially when Meshcore uses the board manufacturers libraries to communicate with the sensors.

Lastly while Meshtastic is using 0x42, I don't see any explanations why they chose this address. I appreciate trying not to reinvent the wheel, but it's very possible that this is a bug on their side too and we're inheriting it.

In it's current state, the INA3221 sensor doesn't work properly. There's more that needs to be done, but this change gets its the bulk of the way there.